Design It!
1章
ビジネス目標を満たすためにとられた全体のソリューションはどのようなものだったか。
どんな技術に取り組んだか。
最大のリスクは何だったか。それらをどのように克服したか。
今もう一度やり直すとしたら、どのようにするか。
大きな問題をより小さく、より管理しやすい問題へと変える
人々の協働の仕方を示す
複雑な問題について会話するための語彙を提供する
フィーチャーや機能以外のものにも目を向ける
コストのかかる間違いを避けるのに役立つ
変化への柔軟な対応を可能にする
2章
3章
デザインスイートスポット
ソフトウェアシステムが大きくなればなるほど、前払いのアーキテクチャ設計から受ける恩恵は大きくなる
大規模（10,000KSLOC）なソフトウェアシステムでは全体の開発スケジュールの37%以上をアーキテクチャ設計に使うのが賢い判断と評価できる
小規模（10KSLOC）のソフトウェアシステムでは、前払いのアーキテクチャ策定からはほとんど恩恵を受けられない
前払いのアーキテクチャ設計に費やすべきなのは、全体の推定開発スケジュールの約5%程度だ
場合によっては、アーキテクチャ設計に時間を多く費やすよりも、小さいソフトウェアシステムを書き直す方が早い場合がある
アーキテクチャ設計に少ししか投資しないと、強烈なしっぺ返しが来ることが予想される
アーキテクチャに投資すればするほど、必要な手直しは少なくなる
リスクは優れた指標
システムについて不安なことを並べ、最も問題を引き起こすものから順に優先順位をつける
すべてのリスクは2つの部分からなる。条件は現在の世界に関する事実だ。そして、結果は状態の直接的な結果として将来発生する可能性のある良くないことだ。 軽減または除去する方法
確率を下げる
影響を軽減する
リスクの時間的制約を取り除く
条件を取り除く
受け入れて何もしない
5章
アーキテクチャ上で重要な要求を見極める
構造の選択に大きく影響する
制約
変更できない設計判断
品質特性
システムが特定の状況でどのように動作するかを特徴づける、外部から観察できる性質
設計時の性質
実行時の性質
概念上の性質
影響を与える機能要求
特別な注意を必要とするフィーチャーや機能
その他の影響を及ぼすもの
時間、知識、経験
6章
設計とは発散と収束の繰り返し
探求する分野
全体構成を決めるため、要素とその役割
すべての要素には明確な責務がある
要素の相互作用を決めるため、関係とインタフェース
アーキテクチャが形作る世界を理解するため、ドメイン
すべての問題にはそれが存在する世界を説明する独自の用語と概念がある
オブジェクトであろうとイベントであろうと概念はアーキテクチャの中で説明されなければいけない
品質特性を追及するため、技術とフレームワーク
デリバリを確実にするため、構築方法やデプロイ方法
意思決定を導く視点を得るため、過去の設計
デリバリの制約を満たすために設計判断に影響が及ぶことがある
並行開発を促進するパターン
インクリメンタルなデリバリを促進するパターン
リスク軽減のため精通している技術を選ぶ
自動化と開発速度を支援する技術
これらの組み合わせを選択する
ステークホルダーは制約がアーキテクチャに与える影響を常に理解しているわけではない
たとえば法務のポリシーで使用できるソフトウェアのライセンスが限定される、など
アーキテクトは相談し、影響を理解してもらい制約を緩める交渉をする
調査と探求の時間を得るため、拘束力のある判断を遅らせる
重要な選択を失うのを避けるために判断をくださなければならない時期まで遅らせる
ソフトウェアに最も良い影響を及ぼすタイミングで設計判断をする
7章
知られているパターンで土台を作ることでゼロから構築した際にはまる罠を避けられる
レイヤーパターン
関心事のまとまりをレイヤーとして分割することで共同作業が容易になる
レイヤーの増加やレイヤー内の抽象が外に漏れだすことで開発が困難になる
ポートとアダプター
コンポーネントからデータやイベントを分離する
アダプターを実行時に差し込む
ポートはインタフェース
パイプとフィルター
Unixパイプ処理がそのもの
フィルターがデータ変換や操作を担当する
パイプでフィルターを組み合わせて繋ぐ
対話性に乏しくユーザインタフェースをつくるのには向かない
producerとconsumerが存在し、互いに独立し、互いを認識しない
イベントバスを介して間接的に通信する
イベントバスにより成否が決まるほど
パフォーマンスを予測するのは困難
Shared-Data
多層 Muti-Tier
コンピタンスセンター
8章
13章
現代のソフトウェアシステム開発は、とても多くの力を必要とする。コンテナ化、超安価なコンピュータ、オンデマンドクラウドインフラストラクチャといった技術の進歩によって、途方もない力と柔軟性が開発者の手に直接届くようになった。こうした途方もない力と柔軟性を持つ新しい技術に応じて、マイクロサービスやFaaS（Function as a Service）といった新興のアーキテクチャパターンでは、開発者が、自分たちの行った判断が品質特性などのシステム特性にどれくらい大きな影響を及ぼすかを強く意識していることが前提となっている。
現代のソフトウェアシステムにおいて、開発者とアーキテクトの違いはほとんどない。これは、現代のソフトウェア開発チームが技術リーダーを必要としないという意味ではない。技術リーダーは現代のソフトウェア開発チームにおいても必要な存在であり、実際にチームの中でアーキテクトの役割を果たしている。
ソフトウェアアーキテクトというものを、単なるチームの役割としてではなく、考え方として受け入れているチームは、より良いソフトウェアを生み出している。チームの大多数がアーキテクトであるなら、チームはより多くの設計判断をより迅速に検討できる。設計判断を批評できるメンバーが多いほど、ソフトウェアの品質は向上する。ドキュメントは少なく済み、より少ない労力で、より多くの知識を伝えることもできる。
メンバー全員がアーキテクトになる
アーキテクチャ設計への共同意識
設計の背後にある意図を理解し、一貫性を維持することへの責任を感じる